Customer No. 27061 

Confirmation No. 7333 



Patent 

Attorney Docket No. GEMS808 1 .08 1 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Application of 

Serial No. 

Filed 

For 

Group Art No. 
Examiner 



Zhang et al. 
09/681,483 
April 13, 2001 

Method and System to Request Remotely Enabled Access 
to Inactive Software Options Resident on a Device 

2135 

Dada, B. 



CERTIFICATION UNDER 37 CFR 1.8(a) and 1.10 

I hereby certify that, on the date shown below, this correspondence is being: 



Transmission 

□ transmitted by facsimile to Fax No.: 571-273-8300 addressed to Examiner Dada at the Patent and Trademark Office. 
■ transmitted by EFS-WEB addressed to Examiner Dada at the Patent and Trademark Office. 
Date: October 2. 2006 



/Robvn L. Templin/ 
Signature 



Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



APPEAL BRIEF PURSUANT TO 37 C.F.R §§1.191 AND 1.192 

Dear Sir: 

This Appeal Brief is being filed in furtherance of the Notice of Appeal filed on July 6, 

2006. 



Zhang et al. 



S/N: 09/681,483 



1. REAL PARTY IN INTEREST 

The real party in interest is General Electric Company, the Assignee of the above- 
referenced application by virtue of the Assignment to General Electric Company recorded on 
May 18, 2001, at reel 011832, frame 0040. 

2. RELATED APPEALS AND INTERFERENCES 

Appellant is unaware of any other appending appeals or interferences related to this 
Appeal. This Appeal Brief is filed in response to the Advisory Action mailed on June 21, 2006. 
The undersigned is Appellant's legal representative in this Appeal. General Electric Company, 
the Assignee of the above-referenced application, as evidenced by the documents mentioned 
above, will be directly affected by the Board's decision in the pending appeal. 

3. STATUS OF THE CLAIMS 

Claims 1-6, 8-13, 15-17 and 19-31 are pending in the present application. Claims 17, 19- 
29, and 31 are currently under final rejection and, thus, are the subject of this appeal. Claims 1-6, 
8-13, 15, 16, and 30 are in condition for allowance. Claims 7, 14, and 18 have been cancelled. 

4. STATUS OF AMENDMENTS 

The Appellant has not submitted any amendments subsequent to the Advisory Action 
mailed on June 21, 2006. 

5. SUMMARY OF CLAIMED SUBJECT MATTER 

A method to access one or more inactive options resident on a device remotely located 

from a centralized facility is called for in claim 1 and includes the steps of accessing a graphical 
user interface (GUI) (102) electronically linked to a centralized facility and configured to 
facilitate selection from a number of option identifying parameters and selecting at least one of 
the number of option identifying parameters for identification of one or more inactive options 
resident on the device (112). Application, Iff 27-28. The method also includes the steps of 
transmitting an electronic request for activation of the selected one or more inactive options to 
the centralized facility, wherein the electronic request is transmitted via a public communication 
interface (18), Id. at % 29, and authorizing transmission and installation of a software key in 
response to the electronic request (116, 120), Id. at 1 29, wherein the transmission of the software 
key is via a private communication interface such that the private communication interface 
electronically connects the centralized facility to the device. Id. at <pi. 

In accordance with another aspect of the current invention, claim 9 calls for an access 
granting system (10) having a computerized network (18) and a device (12, 14) having at least 
one non-enabled software application resident in memory thereon. Application, % 17. The access 
granting system (10) also includes a plurality of computers (22), Id. at 1 18, connected to the 
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computerized network, wherein at least one of the plurality of computers displays selection data 
to a user in a form of a graphical user interface (GUI) (200). Id. at \ 33. Access granting system 
(10) further includes a remote centralized facility (16), Id. at %_ 19, electronically connected to the 
device and having a database, wherein the remote centralized facility (16) includes a computer 
programmed to: receive a host ID input, wherein the host ID corresponds to a physical location of 
the device; identify a user selection of the at least one non-enabled software application; receive a 
request from an authorized user requesting enablement of the identified user selection; generate a 
software enabler designed to permit access to the selected non-enabled software application in 
accordance with the received request; and transmit the software enabler from the centralized 
facility to the device. Id. at fj[ 27-31. 

In accordance with yet another aspect of the current invention, claim 17 calls for a 
computer data signal process embodied in a carrier wave and representing a sequence of 
instructions originating from a computer program executed by a computer which, when executed 
by at least one processor, causes the at least one processor to display a GUI (200) configured to 
facilitate a request over a first communication interface to enable an inactive option resident on a 
remote device (102). Application, %_ 27. The processor also receives an input of a device 
identifier (106), receives a selection of a usage period (114), and receives a selection of an 
inactive option for enablement from the GUI (112). Id., 11 27-28. The processor further causes a 
remote centralized processing station to generate a code configured to enable the selected inactive 
option after successful processing of the received inputs and selections (130, 134) and transmit 
the code to the device having the inactive option over a second communication interface different 
from the first communication interface (136, 138). Id. at <f][ 29-31. 

According to a further aspect of the current invention, claim 24 calls for a GUI to request 
activation of an inactive software program resident in memory of a medical imaging scanner 
remotely located from a centralized processing center comprising a device modality selector 
(226) and a system identification field (222). Application, %_ 10. A user identification field (224), 
software program selector (232), and a software key generation tab (246) are also set forth. Id. at 
1 10. User selection of the software key generation tab (246) transmits a data transmission over a 
public communication connection to the centralized processing center, wherein the data 
transmission represents a request to activate the inactive software program resident in memory of 
the medical imaging scanner over a private communication connection. Id. at % 10. 
6. GROUNDS OF REJECTION : 

The Examiner has rejected claims 17 and 19-23 under 35 U.S.C. §101. Additionally, 
claims 17, 19, 21-23 and 31 have been rejected under 35 U.S.C. § 102(e) as being anticipated by 
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Moeller et al. (USP 6,694,384). The Examiner has further rejected claims 20 and 24-29 under 35 
U.S.C. § 103(a) as being unpatentable over Moeller et al. in view of Applicant's Admitted Prior 
Art. 

7. ARGUMENT 
Rejection Under 35 U.S.C. §101 

Claims 17 and 19-23 

The Examiner rejected claims 17 and 19-23 under 35 U.S.C. §101 as being directed to 
unpatentable subject matter. Claim 17 calls for a computer data signal process embodied in a 
carrier wave and representing a sequence of instructions originating from a computer program 
executed by a computer which, when executed by at least one processor, causes the at least one 
processor to carry out a sequence of process steps. Appellant contends that claim 17 calls for a 
statutory process that is directed to a practical application of a data signal. 

In the Advisory Action of June 21, 2006, the Examiner rejected the claim, stating that 
"claim 17 is directed to a data signal, a data signal does not fall within one of the four statutory 
classes of 101." Advisory Action, 06/21/06, pg. 2. The Examiner's continued rejection ignores 
the substance of what is being called for in the claim. Claim 17 calls for a computer implemented 
process . Computer-implemented processes are statutory so long as they are limited to a practical 
application within the technological arts. See MPEP § 2106; see also Diamond v. Diehr , 450 
U.S. 175, 183-184 (1981). A claim is limited to a practical application when the process, as 
claimed, produces a concrete, tangible and useful result; i.e., the process recites a step or act of 
producing something that is concrete, tangible, and useful. MPEP § 2106; see AT&T Corp. v. 
Excel Communications, Inc. , 172 F.3d 1352, 1358 (Fed. Cir. 1999). Claim 17 recites the 
practical application of a process that causes a processor to perform a series of process steps. The 
process acts carried out by the processor are a practical application of the process in that they 
cause the processor to: display a GUI, cause a remote processing station to generate a code, and 
transmit the code to a device having an inactive option. The process therefore produces a 
concrete, tangible, and useful result, and thus results in a practical application. In light of the 
foregoing, Applicant believes that claim 17, and the claims dependent therefrom, are directed to 
statutory subject matter. As such, Applicant respectfully requests the Board to withdraw the 
rejection under §101. 
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Rejection Under 35 U.S.C. §102(e) as Being Anticipated by Moeller et al. (USP 6,694,384) 

Claims 17. 19. 21 and 22 

Claim 17 has been rejected as being anticipated by Moeller et al. Claim 17 calls for, in 
part, a computer data signal process originating from a computer program executed by a 
computer which, when executed by at least one processor, causes the at least one processor to 
display a GUI configured to facilitate a request over a first communication interface to enable an 
inactive option resident on a remote device, cause a remote centralized processing station to 
generate a code configured to enable the inactive option and transmit the code to the device 
having the inactive option over a second communication interface different from the first 
communication interface. 

In making the § 102(e) rejection, the Examiner asserted that "Moeller teaches displaying a 
GUI (i.e., selection from a menu) configured to facilitate a request over a first communication 
interface to enable an inactive option resident on a remote device... [column 4, lines 29-35 and 
lines 63-67] and transmitting the code to the device having the inactive option over a second 
communication interface different from the first communication interface [column 4, lines 41-46 
and column 5, lines 1-10]." Advisory Action, supra at 2. The Examiner reached this conclusion 
notwithstanding that Moeller et al. fails to teach or suggest the use of a first communication 
interface to enable an inactive option resident on a remote device that is different from a second 
communication interface for transmitting the code to the device. 

Moeller et al. is directed to a method and system to remotely configure business office 

devices to user defined parameters. Specifically, the reference discloses "a method and system 

for configuring and/or re-configuring an office device to satisfy each user's particular needs." 

Moeller et al. '384, Abstract. Moeller et al. further states: 

FIG. 2 illustrates the method in which a user selects the desired soft features 
40 for the limited feature scanner 50. Initially, the user obtains a limited 
feature scanner from the scanner company. The scanner is equipped to 
provide a number of features, however, these features are initially disabled 
and/or set at a minimum level. After accessing the system configuration 
port 30, the user enters a scanner unit identification number (ID) 170 unique 
to the user's limited feature scanner 50. The system configuration port 30 
confirms the ID 170 and uploads to the user's PC 10 those soft features 40 
that are currently available. The user then selects those soft features 40 that 
he wishes to enable or download to his limited feature scanner 50. Payment 
190 for the soft features 40 is then secured via a secured internet transaction 
or other secure means. After payment, the user then receives an access key 
or access code 140 to enter into the scanner for the scanner to configure 
itself by enable the features selected, and disabling the unselected features 
when necessary. 
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The access key 140 is entered into the limited feature scanner 50 either by 
the user via an alphanumeric keypad on the scanner or via the workstation 
keypad, or by sending a code or file of information to be loaded into the PC 
workstation. The limited feature scanner 50 then configures its soft features 
40 in accordance with the access key 140 provided to it by the user. The 
user can then reconfigure the scanner by repeating the above described 
steps. 

In an alternate embodiment of the invention, the system configuration port, 
utilizing either the internet connection model 20 or the download application 
25 enables and/or disables the hard features of the limited feature scanner 
50 in accordance with desire or requirements of the user. 

Id., Col. 4, 11. 27-58. 

As set forth above, Moeller et al. discloses a system whereby a user accesses a list of 
available features through an interface on the office device to be reconfigured. Once the desired 
features are selected, payment is secured over the internet or other secure means. The user then 
receives an access key or code to input into the scanner. In an alternate embodiment, Moeller 
discloses that the access key can be sent to the office device directly. See id. at Col. 4, 11. 46-50. 
In neither case, however, is the feature enablement request made over a first communication 
interface and access key or code transmission over a second communications interface that is 
different from the first communications interface . In the system of Moeller et al., both the request 
and the key transmission are transmitted over the internet or other secure means. There is no 
disclosure for use of two different communication interfaces. 

In another embodiment, Moeller et al. discloses that a feature enablement request can be 

made in a telephonic request initiated by a user. This alternate embodiment is described below. 

FIG. 3 illustrates a flow chart of another embodiment of the present 
invention in which a user can remotely configure the scanner by telephoning 
the scanner company, when the user does not have access to a modem or 
internet connection. In this embodiment, the user calls the scanner company 
to turn on the desired feature selected from a menu at step 200. The user 
provides the scanner company the user's information, the scanner ID 
number, and the desired features at step 210. In turn, the scanner company 
gives the user an access code at step 220 which will allow the scanner to 
configure itself. The scanner company maintains a database of the user's 
information and the access code. The access code can take any form, but 
preferably is a unique set of letters and numbers corresponding to any 
possibly menu selection, i.e., any combination of features. 

Once the access code is provided to the user, the billing cycle commences 
and the customer is billed at step 240. The customer inputs the access code 
into the scanner at step 260, and the scanner configures itself or enables the 
selected menu items, at step 270. 

Id. at Col. 4, 11. 59-67 and Col. 5, 11. 1-11. 
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In this embodiment, Moeller et al. discloses that, in response to a telephonic request, "the 
scanner company gives the user an access code ... which will allow the scanner to configure 
itself. . .The customer inputs the access code into the scanner. . ." Id. As such, both the request and 
the access key are transmitted in a common communications interface - namely, a telephone call. 
This is in stark contrast to that called for in claim 17, which calls for a first communications 
interface to facilitate a feature enablement request and a second communications interface to 
facilitate a key transmission, the second communications interface being different from the first 
communications interface. 

Moeller et al. clearly discloses that both the request and the key transmission for 
configuring an office device are made over the same communication interface. The Examiner has 
improperly identified two separate communication interfaces in the described embodiments. 
Nowhere in the above description is the feature enablement request made over a first 
communication interface and access key or code transmission over a second communications 
interface that is different from the first communications interface. Instead, both the request and 
the key transmission are made over the same interface, that being only one of either the internet, 
telephone, or other secure means. Claim 17 specifically calls for an enablement request to be 
made over a first communication and for transmission of a code over a second communication 
interface different from the first communication interface. Therefore, Moeller et al. cannot 
anticipate that which is called for in claim 17. As such, claim 17 and the claims that depend 
therefrom, including claims 19, 21, and 22, are patentably distinct over the art of record. 
Claim 23 

Claim 23, which is dependent from claim 17, additionally calls for the GUI to be 
configured to allow selection of one of a trial use period, a limited use period, a pay-per-use 
period, and an indefinite use period for the inactive option. In rejecting claim 23, the Examiner 
stated that Moeller et al. further teaches that "the GUI is configured to allow selection of one of a 
trial use period, a limited use period, a pay-per-use period, and indefinite use period for the 
inactive option." Office Action, 04/06/06, p. 2. However, such a feature is not disclosed or taught 
in the cited reference. Moeller et al. discloses that a user is free to use the scanner with the 
selected features for a desired period of time, and that the user is billed repeatedly over a set 
period of time. Moeller et al., Col. 5, 11. 12-15. However, Moeller et al. makes no disclosure of 
the system being configured to allow a user a trial use period or a pay-per-use period as is called 
for in claim 23. Rather, as stated above, Moeller et al. discloses that a user is billed for a set 
period of time . Such a configuration does not allow for a free trial period or a pay-per-use option. 
As such, claim 23 is also patentably distinct over Moeller et al. 
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Claim 31 

Claim 31, which is dependent from claim 17, further calls for the first communication 
interface therein to be a public communication interface, and the second communication interface 
therein to be a private communication interface. Similar to that which is described above 
regarding claim 17, Moeller et al. does not teach or disclose a first communication interface to be 
a public communication interface, and a second communication interface to be a private 
communication interface. Moeller et al. only teaches the system therein to make use of a single 
communication interface. As the request and activation performed in claim 31 are made over 
public and private communication connections respectively, they necessarily are made over two 
separate connections. The single interface taught and disclosed in Moeller et al. cannot be both a 
public and a private communication interface. As such, claim 31 is patentably distinct over 
Moeller et al. 

Rejection Under 35 U.S.C. §103(a) as Being Unpatentable Over Moeller et al. (USP 
6,694,384) in View of Appellant's Admitted Prior Art 

Claims 20 and 24-29 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Moeller et al. (USP 6,694,384) in view of Appellant's Admitted Prior Art (AAPA). However, 
claims 20 and 24-29 are patentable over Moeller et al. and AAPA because the Examiner has 
failed to establish a prima facie case of obviousness. The burden of establishing a prima facie 
case of obviousness falls on the Examiner. MPEP § 2142. To establish a prima facie case, the 
Examiner must show three things. First, there must be some suggestion or motivation, either in 
the references themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art references must teach or suggest all the 
claim limitations. MPEP § 2143. Here, the Examiner has failed to show that the combination of 
Moeller et al. and AAPA teaches or suggests each and every element of the claimed invention. 
Claim 20 

Claim 20, which is dependent from claim 17, calls for the remote device therein to be a 
medical device, including one of a cardiology device, a computed radiology device, a computed 
tomography device, a magnetic resonance imaging device, an x-ray device, an ultrasound device, 
a picture archiving and communication device, a nuclear medicine device, and a positron 
emission tomography device. As claim 20 is dependent from claim 17, all the elements of claim 
17 are read into that which is called for in claim 20. As described above, Moeller et al. fails to 
teach or disclose that which is called for in claim 17. Specifically, Moeller et al. fails to teach or 
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disclose an enablement request to be made over a first communication interface and for 
transmission of a code over a second communication interface different from the first 
communication interface. 

AAPA also makes no teaching, disclosure, or suggestion of an enablement request to be 
made over a first communication interface and for transmission of a code over a second 
communication interface different from the first communication interface. AAPA thus adds 
nothing to the teaching and disclosure of Moeller et al. that would render claim 20 obvious 
thereover. That is, AAPA merely discloses that medical imaging systems have, in the prior art, 
been configured to generically enable data exchange between a centralized facility and the remote 
medical imaging system. Nowhere, however, does AAPA suggest that this remote data exchange 
has the capacity to enable inactive options resident on the imaging system. Therefore, the 
combination of AAPA with Moeller et al. still fails to teach, disclose, or suggest all of the 
elements set forth in claim 20, pursuant to the chain of dependency from claim 17. As such, 
claim 20 is patentably distinct over the cited references. 
Claim 24 

Claim 24 has been rejected under the combination of Moeller et al. and AAPA, as being 
obvious thereover. Claim 24 calls for, in part, a GUI to request activation of an inactive software 
program resident in memory of a medical imaging scanner remotely located from a centralized 
processing center having a software key generation tab, whereupon user selection of the software 
key generation tab transmits a data transmission over a public communication connection to the 
centralized processing center, and wherein the data transmission represents a request to activate 
the inactive software program resident in memory of the medical imaging scanner over a private 
communication connection. 

The Examiner has asserted that "Moeller teaches a GUI to request activation of an 
inactive software program resident in memory of a scanner remotely located from a centralized 
processing center comprising. . . a software key generation tab, where upon user selection of the 
software key generation tab transmits a data transmission over a public communication 
connection to the centralized processing center, and wherein the data transmission represents a 
request to activate the inactive software program resident in memory of the scanner over a private 
communication connection." Office Action, supra at 4-5. As set forth above with regard to claims 
17 and 31, in the several embodiments of the system disclosed by Moeller et al., a feature 
enablement request and a key transmission are made over the same connection - either internet or 
telephone. As the request and activation performed in claim 24 are made over public and private 
communication connections respectively, they necessarily are made over two separate 
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connections. Such is not the case in Moeller et al., which clearly fails to teach or suggest 
communicating a feature request over a public communication connection and communicating a 
software key over a private communication connection. AAPA also makes no teaching, 
disclosure, or suggestion of such a public communication interface and private communication 
interface, as is set forth in detail above. Therefore, the combination of Moeller et al. and AAPA 
fails to teach, disclose, or suggest all of the elements set forth in claim 24. Thus, claim 24 is 
patentably distinct over the combination of Moeller et al. and AAPA. 
Claims 25-29 

Claims 25-29 further define the GUI called for in claim 24 and are patentably distinct 
over Moeller et al. and Appellant' s admitted prior art at least pursuant to the chain of dependency. 
As described above, the combination of Moeller et al. and AAPA fails to teach, disclose, or 
suggest that which is called for in claim 24, and thereby fails to teach, disclose or suggest that 
which is called for in claims 25-29 pursuant to the chain of dependency from claim 24. 
8. CONCLUSION 

In view of the above remarks, Appellant respectfully submits that the Examiner has 
provided no supportable position for the rejection of claims 17, 19-29, and 31. Accordingly, 
Appellant respectfully requests that the Board find claims 17, 19-29, and 31 patentable over the 
prior art of record and withdraw all outstanding rejections. 

General Authorization for Extension of Times 

In accordance with 37 C.F.R. 1.136, Appellant hereby provides a general authorization to 
treat this and any future reply requiring an extension of time as incorporating a request therefore. 
Furthermore, Appellant authorizes the Commissioner to charge deposit account no. 07-0845 the 
appropriate fee for an extension of time or any other fee which may be due. 

Respectfully submitted, Respectfully submitted, 

/Timothy J. Ziolkowski/ /Kevin R. Rosin/ 

Timothy J. Ziolkowski Kevin R. Rosin 

Registration No. 38,368 Registration No. 55,584 

Direct Dial 262-376-5139 Phone 262-376-5170 ext. 15 

tjz@zpspatents.com krr@zpspatents.com 

Dated: October 2, 2006 

Attorney Docket No. : GEMS 808 1 .08 1 

P.O. ADDRESS: 

Ziolkowski Patent Solutions Group, SC 
14135 North Cedarburg Road 
Mequon,WI 53097-1416 
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CLAIMS APPENDIX 

1 . (Previously Presented) A method to access one or more inactive options resident 
on a device remotely located from a centralized facility comprising the steps of: 

accessing a graphical user interface (GUI) electronically linked to a centralized 
facility and configured to facilitate selection from a number of option identifying parameters; 

selecting at least one of the number of option identifying parameters for 
identification of one or more inactive options resident on the device; 

transmitting an electronic request for activation of the selected one or more 
inactive options to the centralized facility, wherein the electronic request is transmitted via a 
public communication interface; and 

authorizing transmission and installation of a software key in response to the 
electronic request, wherein the transmission of the software key is via a private communication 
interface such that the private communication interface electronically connects the centralized 
facility to the device. 

2. (Previously Presented) The method of claim 1 wherein the software key is 
configured to activate the one or more inactive options and is transmitted to and installed on the 
device. 

3. (Original) The method of claim 1 further including the steps of inputting a 
system ID, a host ID, a client ID, and a password to gain access to the selection step. 

4. (Original) The method of claim 1 further comprising the step of formulating the 
electronic request by: 

inputting a user ID; 
inputting a system ID; 
selecting a modality; 
selecting a software package; and 
selecting a usage period. 

5. (Original) The method of claim 1 further comprising the step of requesting use 
of the one or more inactive options for one of a trial period, a pay-per-use period, a limited access 
period, and an indefinite period. 
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6. (Original) The method of claim 1 further comprising generating a software key 
if the centralized facility grants access to the inactive option, wherein the software key is unique 
for each electronic request. 

7. (Canceled) 

8. (Previously Presented) The method of claim 2 wherein the software key is an 
alphanumeric code. 

9. (Previously Presented) An access granting system comprising: 
a computerized network; 

a device having at least one non-enabled software application resident in memory 

thereon; 

a plurality of computers connected to the computerized network, wherein at least 
one of the plurality of computers displays selection data to a user in a form of a graphical user 
interface (GUI); 

a remote centralized facility electronically connected to the device and having a 
database, wherein the remote centralized facility includes a computer programmed to: 

receive a host ID input, wherein the host ID corresponds to a physical 

location of the device; 

identify a user selection of the at least one non-enabled software 

application; 

receive a request from an authorized user requesting enablement of the 
identified user selection; 

generate a software enabler designed to permit access to the selected 
non-enabled software application in accordance with the received request; and 

transmit the software enabler from the centralized facility to the device. 

10. (Previously Presented) The system of claim 9 wherein the computer of the 
centralized facility is further programmed to: 

receive a system ID input; 
identify a modality selection; and 
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decide whether to generate and transmit the software enabler based on the host 
ID input, the system ID input, and the modality selection. 

1 1 . (Original) The system of claim 9 wherein the computer of the centralized facility 
is further programmed to compare the request comprising a system ID, a host ID, a user ID, a 
selected non-enabled software application; and an identified modality to user and device data 
stored in the database, and generate the software enabler, wherein the software enabler is specific 
to the request and non-reusable. 

12. (Original) The system of claim 10 wherein the computer of the centralized 
facility is further programmed to determine if the user is authorized to operate the selected non- 
enabled software application. 

13. (Original) The system of claim 9 wherein the device is a medical component 
including one of a cardiology device, a computed radiology device, a computed tomography 
device, a magnetic resonance imaging device, an x-ray device, an ultrasound device, a picture 
archiving and communication device, a nuclear medicine device, and a positron emission 
tomography device. 

14. (Canceled) 

15. (Original) The system of claim 9 wherein the GUI is configured to authorize 
electronic communication between the centralized facility and the device. 

16. (Original) The system of claim 9 wherein a user selection of a modality causes a 
list of available software applications to be displayed on the GUI. 

17. (Previously Presented) A computer data signal process embodied in a carrier 
wave and representing a sequence of instructions originating from a computer program executed 
by a computer which, when executed by at least one processor, causes the at least one processor 
to: 

display a GUI configured to facilitate a request over a first communication 
interface to enable an inactive option resident on a remote device; 
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receive an input of a device identifier; 
receive a selection of a usage period; 

receive a selection of an inactive option for enablement from the GUI; 

cause a remote centralized processing station to generate a code configured to 
enable the selected inactive option after successful processing of the received inputs and 
selections; and 

transmit the code to the device having the inactive option over a second 
communication interface different from the first communication interface. 

18. (Canceled) 

19. (Previously Presented) The computer data signal process of claim 17 wherein the 
code includes an alphanumeric software key. 

20. (Previously Presented) The computer data signal process of claim 17 wherein the 
device is a medical device including one of a cardiology device, a computed radiology device, a 
computed tomography device, a magnetic resonance imaging device, an x-ray device, an 
ultrasound device, a picture archiving and communication device, a nuclear medicine device, and 
a positron emission tomography device. 

21. (Previously Presented) The computer data signal process of claim 17 wherein the 
GUI is accessible via a public communication network and configured to permit communication 
between a user station and the centralized facility. 

22. (Previously Presented) The computer data signal process of claim 17 wherein the 
set of instructions further causes the at least one processor to receive an input of a user ID, a 
client ID, a system ID, a facility ID, and a selection of a device modality and a software package 
from the GUI. 

23. (Previously Presented) The computer data signal process of claim 17 wherein the 
GUI is configured to allow selection of one of a trial use period, a limited use period, a pay-per- 
use period, and an indefinite use period for the inactive option. 
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24. (Previously Presented) A GUI to request activation of an inactive software 
program resident in memory of a medical imaging scanner remotely located from a centralized 
processing center comprising: 

a device modality selector; 
a system identification field; 
a user identification field; 
a software program selector; and 

a software key generation tab, whereupon user selection of the software key 
generation tab transmits a data transmission over a public communication connection to the 
centralized processing center, and wherein the data transmission represents a request to activate 
the inactive software program resident in memory of the medical imaging scanner over a private 
communication connection. 

25. (Original) The GUI of claim 24 wherein the device modality selector includes a 
drop-down menu and is configured to display a listing of device modalities including computed 
tomography, x-ray, magnetic resonance, echocardiography, ultrasound, nuclear medicine, and 
positron emission tomography. 

26. (Original) The GUI of claim 24 further comprising a period-of-use selector. 

27. (Original) The GUI of claim 26 wherein the period-of-use selector includes a 
drop-down menu configured to display, in response to a user push-button instruction, a usage 
period including a trial period usage, a limited-use period usage, a pay-per-use period usage, and 
an indefinite period usage. 

28. (Original) The GUI of claim 24 wherein the data transmission is configured to 
represent a request to activate more than one inactive software program resident in memory of the 
medical imaging scanner. 

29. (Original) The GUI of claim 24 further comprising a generate-and-receive 
button, wherein a user selection of the generate-and-receive button creates the data transmission 
and represents an authorization to request generation of a software key at the centralized 
processing center and transmit the software key to the medical imaging scanner. 
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30. (Previously Presented) The system of claim 9 wherein the computer of the 
centralized facility is further programmed to: 

receive a user ID input; and 

verify authorization of the user ID input to request enablement of the identified 

user selection. 

31. (Previously Presented) The computer data signal process of claim 17 wherein the 
first communication interface is a public communication interface, and wherein the second 
communication interface is a private communication interface. 
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